Initially, a structure of services and/or features offered over networks (e.g., telecommunications networks, the Internet, etc.) was directly between real computing and/or storage hosts, in what is commonly called the edge-to-edge principle. The services/features were usually client-server, server-server, or client-client oriented.
Intermediate network nodes, provided in such networks, operated only at the Internet layer (e.g., routers) or the link layer (e.g., Ethernet switches) using either routing or bridging protocols. Some of these networking protocols were augmented to implement various forms of virtualization, such as virtual circuits and multiple access virtual private networks. These forms of network virtualization were achieved by adding header fields to packets, such as Internet protocol (IP) tunnel headers, multiprotocol label switching (MPLS) label stack headers, and/or extended Ethernet fields (e.g., virtual local area network (VLAN) tags), in conjunction with augmenting the routing and signaling protocols to distribute this information. This resulted in multiple logically separate, or virtual, networks, often referred to as Virtual Private Networks (VPNs).
Services/features provided by networking and computing resources are often implemented as overlays on networks (e.g., the Internet and/or VPNs). Furthermore, an enrichment of services has occurred, with the rise of middle-boxes, or feature peers, which operate above the Internet layer at the transport and/or application layers. The feature peers may include gateways provided between VPNs and the Internet, network address translation (NAT) devices, firewalls, intrusion detection devices, proxies of various forms, content filtering devices, caches, web acceleration devices, multimedia transcoding and statistics collection devices, etc. The feature peers, as part of service structures (i.e., feature networks), deviate from the original edge-to-edge principle, and require adherence to a different set of guiding principles to implement a reliable, traffic-engineered system that will achieve the goal of a converged service infrastructure.
Some networks provide packet and/or application flow services and/or features via one or more feature peers (i.e., middle boxes that communicate amongst themselves and not necessarily with a client or server). Examples of such packet/application flow services/features include content-related services (e.g., voice, audio, and/or video transcoding; multi-media conference bridging; replication; content filtering; content recognition; etc.); security-related services (e.g., network-based firewalls and/or application layer gateways; intrusion detection, prevention, and/or mitigation; denial of service detection, prevention, and/or mitigation; etc.); flow, rate, and quality of service (QoS)-related services (e.g., metering; policing; shaping; scheduling; coordination with higher-level signaling, policy, and configuration; caching; etc.); statistics collection and accounting-related services (e.g., usage cap metering, notification, and/or enforcement; billing; etc.); administrative-related services (e.g., selective packet set capture, replication, redirection, and/or blocking; packet inspection; etc.); proxy-related services where a feature peer acts on behalf of a client and/or server which is either (temporarily) off the network and/or in a failure/recovery state; etc.
Such packet/application flow services/features may be managed via a “star” or “flower” network centered on a feature switch. In the star/flower arrangement, traffic to/from a customer (e.g., of a service or feature) is directed into a set of feature peers by the feature switch. Such an arrangement may require configuration of the feature switch, use/configuration of tunnels, and configuration of load balancing, and may result in sub-optimal performance. The star/flower arrangement is expensive because, the feature switch (e.g., an access router, a load balancer, a tunnel gateway, or a traffic steering application (TSA) executing on a server), the routers and switches are traversed twice between each feature peer and the feature switch that connects to a customer and/or a router on the edge of a data center connected to the Internet and/or a virtual private network (VPN). In the star/flower arrangement, there needs to be a tunnel for each feature peer since a tunnel identification (ID) determines a next feature peer or an exit to a data network. Furthermore, the star/flower arrangement can increase latency if the feature peers are not near the feature switch that connects to the customer and the feature switch that connects to the feature peers. The star/flower arrangement requires a static configuration, in the feature switch, of tunnel IDs and next hops, and is resilient only if a dedicated replica of the feature peers is provisioned. If a dedicated replica of the feature peers is not provisioned, then reconfiguration is needed in response to failures (e.g., load balancing across the feature peers requires reconfiguration), and it is difficult to represent more complex feature topologies than a chain feature topology or is complex to implement dynamic feature networks, also referred to as service graphs.
Packet/application flow services/features may also be managed via a service header-based routing arrangement. In one example service header-based routing arrangement, a feature switch registers with a service broker, and the service broker provisions a table (e.g., of the feature switch) to map customer packets to a service routing function (e.g., associated with the feature switch). The service broker provisions service nodes with service header, tunnel, network, and subscriber information consistent with provisioning of the service routing function for the feature switch and/or edge router that connects to a destination of a customer in the network. The feature switch or edge router determines data network information, and receives a packet from a customer (e.g., from a device associated with the customer) or from the Internet/VPN. The access/edge router uses the table to determine that the packet includes subscribed to services and directs the packet to the service routing function. The service routing function uses local configuration and packet information to determine a service header to be inserted, encapsulates this within a tunnel header, and forwards the packet to a first service node over the tunnel. The service node decapsulates the packet from the tunnel, reviews the service header and configured information from the service broker to determine an outgoing tunnel, and forwards the packet to the next service node. Eventually, the packet returns to the access/edge router that originally received the packet. The service routing function decapsulates the packet from the tunnel, examines the service header, and determines that the next step is forwarding. The access/edge router then forwards the packet, via the data network, toward a destination address.
The service header-based routing arrangement requires expensive changes to the software and/or hardware of the access/edge router in order to implement the service header insertion and processing and to make it behave as a feature switch. The service header-based routing arrangement relies on a centralized service broker to determine, download, and monitor state, and to optimize and load balance service node level routing across a set of service nodes. Centralization may limit a convergence time and responsiveness to change associated with the arrangement. Furthermore, the service header-based routing arrangement requires fault detection and restoration performance to be determined by the centralized service broker, and may not be implemented across more than one service provider.